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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Conmiittee Intelligent Transport Systems 
(ITS). 

The present document is part 1 of a multi-part deliverable covering the ITS applications and facilities layer, as identified 
below: 

Part 1: "Facility layer structure, functional requirements and specifications"; 

Part 2: "Applications and facilities layer common data dictionary". 

The present document has been prepared by considering feedback from the Car-to-Car Communication Consortium 
(C2C-CC). The specifications of facilities layer structure and facilities layer entities are based on experience gathered 
from various European Projects such as DRIVE C2X, CVIS, SCORE@F and simTD. 



Introduction 



The present document provides architecture and functional specifications for the facilities layer of the ITS station 
(ITS-S) as defined in [1]. It is based on the previous work that has been realized within ETSI TC ITS WGl related to 
the Basic Set of Applications (BSA) [i.l]. 

ITS applications are distributed among multiple ITS-Ss in order to share information using wireless communications. 
ITS applications provide a large diversity of customer's services. BSA has been defined by ETSI TC as a set of ITS 
applications that can be deployed reasonably within a three-year time frame after its standardization completion. 
Furthermore, ETSI TC ITS developed and defined functional requirements for BSA [i.2]. 

This previous work will allow ETSI TC ITS to identify a set of facilities in the facilities layer that are required to satisfy 
some common functional requirements and operational requirements of BSA. The facilities specified in the present 
document are minimum functionalities, services and data that are needed to ensure the interoperability and basic 
operation of ITS applications. The architecture of the facilities layer is intended to be an open architecture, which is 
available for ITS application developers to incorporate advanced proprietary facilities and different kinds of access 
networks such as ITS G5 or cellular networks. 

The following projects and organizations had been consulted during the preparation of the present document: 

• Car to Car Communication Consortium ( http://www.car-to-car.org) 

• COMeSafety ( http://www.comesafety.org) 

• PREDRIVE C2X ( www.pre-drive-c2x.eu) 

• DRIVE C2X ( http://www.drive-c2x.eu) 

• CVIS ( www.cvisproject.org) 

• simTD ( www.simtd.de ) 
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• CoVel ( www.covel-project.eu) 

• SCORE @F ( http://www.scoref.fr/) 
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1 Scope 



The present document defines the functional architecture for the facihties layer of the ITS station as defined in [1] and 
provides functional requirements and specifications for main identified facilities. 

The identified facilities are required to support BSA as defined in [i.l]. Other proprietary facilities might be required to 
be included in the facilities layer for BSA and other ITS applications. Such proprietary facilities are not defined in the 
present document. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI EN 302 665 (VI. 1.1): "IntelHgent Transport Systems (ITS); Communications Architecture". 

[2] ETSI EN 302 637-2: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set 

of Applications; Part 2: Specification of Cooperative Awareness Basic Service". 

[3] ETSI EN 302 637-3: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set 

of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic 
Service". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TR 102 638 (VI. 1.1): "Intelligent Transport Systems (ITS); Vehicular Communications; 

Basic Set of Applications; Definitions". 

[i.2] ETSI TS 102 637-1 (VI. 1.1): "Intelligent Transport Systems (ITS); Vehicular Communications; 

Basic Set of Applications; Part 1: Functional Requirements". 

[i.3] CEN/TS 16157-1: "Intelligent transport systems - DATEX II data exchange specifications for 

traffic management and information - Part 1 : Context and framework" . 

[i.4] ETSI TS 102 890-2: "Intelligent Transport Systems (ITS); Facilities layer function; Part 2: 

Services announcement specification". 

[i.5] ETSI TR 102 893 (VI. 1.2): "IntelHgent Transport Systems (ITS); Security; Threat, Vulnerability 

and Risk Analysis (TVRA)". 

[i.6] ETSI TS 103 084: Intelligent Transport Systems (ITS); Vehicular Communications; 

GeoMessaging Enabler" . 
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[i.7] ETSI EN 302 636-4-1: "Intelligent Transport System (ITS); Vehicular communications; 

GeoNet working; Part 4: Geographical addressing and forwarding for point-to-point and 
point-to-multipoint communications; Sub-part 1: Media-Independent Functionality " . 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in [1] and the following apply: 

application support: sub set of facilities, providing support elements for ITS applications 

backend systems: system that includes middleware in the generic domain, providing back end support and functions 
for BSA ITS use case 

basic set of applications: group of applications, supported by vehicular communication system 

NOTE: BSA definition is provided in [i.l] 

CA basic service: facility at the facilities layer to support ITS applications, CAM management and CAM dissemination 

communication support: sub set of facilities, providing support for communications 

cooperative awareness message: ITS facilities layer PDU providing ITS-S information 

decentralized environmental notification message: ITS facilities layer PDU providing event information 

DEN basic service: facility at the facilities layer to support ITS applications, DENM management and DENM 
dissemination 

facility: functionalities, services or data provided by the facilities layer 

information support: sub set of facilities, providing support for data management 

ITS application: component of ITS applications layer 

ITS use cases: procedure of executing an ITS application 

LDM: local georeferenced database 

message: facilities layer or application layer PDU 

NOTE: Examples are cooperative awareness message and decentralized environmental notification message. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AID Application identifier 

ALERT-C Advice and problem Location for European Road Traffic 

API Application Programming Interface 

ASN. 1 Abstract Syntax Notation One 

BSA Basic Set of Application 

C2C-CC Car to Car Communication Consortium 

CA Cooperative Awareness 

CAM Cooperative Awareness Message 

CF Common Facility 

DCC Decentralized Congestion Control 

DEN Decentralized Environmental Notification 

DENM Decentralized Environmental Notification Message 

DF Domain Facility 
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DGPS Differential Global Positioning System 

DIASER DIAlogue Standard for traffic Regulation Equipment 

E2E End to end 

EFCD Extended vehicle floating car data 

EGNOS European Geostationary Navigation Overlay Service 

FA-SAP Facilities Application SAP 

GNSS Global Navigation Satellite System 

HMI Human Machine Interface 

HTTP Hypertext Transfer Protocol 

ISO International Organization for Standardization 

ITS Intelligent Transport System 

ITS-S ITS station 

IVS In vehicle signage 

LDM Local Dynamic Map 

MF-SAP Management Facilities SAP 

N&T Networking and transport layer 

NF-SAP Networking and transport Facilities SAP 

OSI Open Systems Interconnection 

PDU Protocol Data Unit 

PER Packed Encoding Rules 

QoS Quality of Service 

RSU Road side unit 

SAM Service Announcement message 

SAP Service Access Point 

SF-SAP Security FaciHties SAP 

SOAP Simple Object Access Protocol 

SPAT Signal Phase And Timing 

TAI International Atomic Time 

TMC Traffic Message Channel 

TMC-LOC TMC Location Referencing 

TOPO Road topology message 

TPEG Transport Protocol Experts Group 

TPEG-LOC TPEG Location Referencing 

TVRA Vulnerability and Risk Analysis 

VMS Variable Message Sign 

XER XML encoding rules 

XML Extensible Markup Language 



ITS application overview 



The overall ITS environment comprises ITS stations (ITS-S) that may communicate directly as follows: 

• From Vehicle to Vehicle, via ad-hoc (or cellular) communication or based on Infrastructure involvement; 

• From Vehicle to Infrastructure; and 

• From Infrastructure to Vehicle. 

ITS-S s may communicate with each other through a local wireless access point (e.g. ITS G5 based) or a wireless wide 
area network (e.g. a cellular network). 
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This is shown in simphfied form in figure 4.1. The dotted Hnes represent the logical connections between ITS-Ss. 
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Figure 4.1 : Simplified view of ITS environment 



4.1 



ITS architecture and ITS stations 



Four ITS-S types are defined in [1], namely: 

• Central ITS-S: A central ITS-S provides centralized ITS applications. A central ITS-S may play the role of 
traffic operator, road operator, services provider or content provider. Furthermore, a central ITS-S may require 
further connection with backend systems via e.g. Internet. For deployment and performances needs, specific 
instances of central ITS-S may contain grouping of Applications or Facilities. 

• Road side ITS-S: A road side ITS-S provides ITS applications from the road side. A road side ITS-S may 
provide ITS applications independently or cooperatively with central ITS-S or other road side ITS-Ss. For 
deployment and performances needs, specific instances of road side ITS-S may contain grouping of 
Applications or Facilities. 

• Vehicle ITS-S: A vehicle ITS-S provides ITS applications to vehicle drivers and/or passengers. It may require 
an interface for accessing in-vehicle data from the in- vehicle network or in vehicle system. For deployment 
and performances needs, specific instances of vehicle ITS-S may contain grouping of Applications or 
Facilities. 

• Personal ITS-S: A personal ITS-S provides ITS applications to personal and nomadic devices. For 
deployment and performances needs, specific instances of personal ITS-S may contain grouping of 
Applications or Facilities. 



ETSI 



11 



ETSI TS 102 894-1 VI. 1.1 (2013-08) 



A common reference communication architecture for all ITS stations is defined in [1] and as illustrated in figure 4.2. 
This architecture is an extension of the ISO 7-layer OSI model. 

The present document defines the functional architecture of the facilities layer. 




Figure 4.2: ITS station reference architecture 



4.2 Application layer overview 



ITS applications are defined within the application layer. An ITS application makes use of the underlying facilities and 
communication capacities provided by the ITS-S. 

The applications layer provides ITS services. Three classes of applications have been defined in [i.l]: road safety, 
traffic efficiency and other applications. Each application can be assigned to one of the three identified application 
classes. 

The Basic Set of Applications (BSA) are applications that are considered as deployable with reasonable efforts within 
3 years' time scale after the complete standardization of the system. Each application regroups a set of use cases to 
realize some user benefits, including societal benefits, mobility benefits or customer benefits. The complete list of the 
BSA use cases and assigned applications are provided in [i.l]. 

The facilities layer is a middleware composed of multiple facilities. A facility is a component that provides functions, 
information or services to ITS applications. It exchanges data with lower layers and with management and security 
entities of the ITS-S as defined in [1]. 

The present document provides specifications of the facilities layer entities in support of the BSA. Further use cases are 
expected to be added in the future. 



5 Facilities layer functional architecture 

5.1 ITS-S external gateways 

In order to connect with external systems, an ITS-S may provide gateway functions for these external systems to 
exchange information with the facilities layer of the ITS-S. For BSA, one or multiple gateway functions may need to be 
developed in order to satisfy the application requirements. 
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5.1 .1 Vehicle ITS-S gateway to in vehicle network 

For a vehicle ITS-S, the facilities layer is connected to the in-vehicle network via an in- vehicle data gateway as 
illustrated in figure 5.1. The facilities and applications of a vehicle ITS-S receive from this gateway the required 
in-vehicle data in order to construct messages (e.g. CAM and DENM) and for the application usage. 

The implementation of the in vehicle data gateway needs to adapt to the specifications of the in vehicle network which 
may be proprietary to the industry. Therefore, the specifications of this gateway are out of the scope of the present 
document. 




Figure 5.1 : Vehicle ITS-S in-vehicle data gateway 

5.1 .2 Road side ITS-S gateway to central ITS-Ss 

A roadside ITS-S is in general connected to a central ITS-S e.g. traffic management centre or road operator centre. In a 
possible road side ITS-S deployment scenario, road side ITS-Ss are managed by a private road infrastructure 
management network. Specific protocols for the traffic management, for the roadside equipment management and 
operational management are applied within such road infrastructure network. A gateway function may be equipped at 
the road side ITS-S in order to provide connections between message exchanges protocols (e.g. CAM, DENM) and 
these infrastructure protocols. In Europe, DATEX II protocol [i.3] is a standardized protocol deployed for exchanges of 
the traffic management information between traffic management centres and between traffic management centre and 
road side equipment (e.g. Variable Message Sign System). In a possible implementation, a roadside ITS-S is connected 
to road infrastructure network by a DATEX II gateway as illustrated in figure 5.2. A road side ITS-S may either receive 
information from central ITS-S or send information to central ITS-S via this gateway. 

The DATEX II gateway of a road side ITS-S may include several functions: 

• Aggregation of the received messages from vehicle ITS-Ss (such as CAM and DENM) and transmit to traffic 
management centre in DATEX II messages. 

• Receive and filter traffic management information from traffic management center in DATEX II protocol, then 
transmit to vehicle ITS-S in messages such as CAM or DENM. 
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Detailed specifications of this gateway is out of the scope of the present document. 
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Figure 5.2: Roadside ITS-S gateway to road infrastructure network 

5.1 .3 Road side ITS-S or central ITS-S gateway to road equipment 

An ITS appHcations may require data related to the traffic regulation (e.g. rail-road intersection, traffic light status, 
speed limit), or require support from the road side detection capacities (e.g. road side sensors). This requires that road 
side equipment exchanges information with central or roadside ITS-S. For example, as specified in [i.2] in the third part 
intersection collision risk warning, a road side ITS-S equipped at the intersection may detect the traffic light violation of 
a vehicle by dedicated road side sensors (e.g. intersection radar, camera), then this road side ITS-S triggers a DENM 
and disseminates to other oncoming vehicles in order to reduce the risk of intersection collision. 

A central or roadside ITS-S may obtain traffic regulation and road side sensor data via a specific gateway to the road 
side equipment as presented in figure 5.3. National or international standards may already exist, e.g. DIASER a French 
standard for information exchanges between traffic light controllers and traffic light equipment. These standards are to 
be taken into account when developing this gateway interface, detailed specifications of this gateway is out of the scope 
of the present document. 




<^^ 




Figure 5.3: Roadside ITS-S gateway to road equipment 
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5.1 .4 ITS-S gateway to back end systems 



An ITS-S (e.g. road side ITS-S or central ITS-S) may need to connect to a back end system via a generic networks such 
as Internet. The back end systems provide required services, service support or service content to the ITS-S in order to 
satisfy the requirements of the ITS appHcations. In a possible implementation, an ITS-S is connected to the back end 
system by a gateway as illustrated in figure 5.4. Detailed specifications of this gateway are out of the scope of the 
present document. 
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Figure 5.4: ITS-S gateway to back end system 

5.1 .5 Personal ITS-S gateway to vehicle ITS station 

When a personal ITS-S is located in a vehicle, this personal ITS-S may be considered as a vehicle ITS-S under the 
condition that the personal ITS-S satisfies some predefined requirements. In particular for a personal ITS-S to support 
the road safety applications, a connection to the vehicle electronics may be required. The personal ITS-S is connected 
securely with vehicle ITS-S via a gateway to the in vehicle network or with the vehicle ITS-S to receive the in vehicle 
data. 

Detailed specifications of this gateway are out of the scope of the present document. 

5.2 Facilities layer functional architecture 

The general functional architecture of the facilities layer is illustrated in figure 5.5. A set of facilities are identified in 
order to support the BSA, these facilities can be classified into two categories as below: 

• Common facilities: Common facilities provide basic core services to support the reliable operation of an 
ITS-S and the interoperability of the BSA applications. Common facilities are common for all ITS-Ss and all 
BSA applications. Examples of the common facilities are time service, positioning service. 

Detailed specifications of the common facilities are provided in clause 6 of the present document. 

• Domain facilities: Domain facilities provide services and functions for one or several specific BSA 
applications such as DEN basic service for cooperative road hazard warning applications. Domain facilities are 
common for one or several applications. One domain facility may become optional or not used for other 
applications. 

Detailed specifications of the domain facilities are provided in clause 7 of the present document. 

Furthermore, according to the functionalities that a facility provides, a facility as identified in the present document can 
be of one of the following types: 

• Application support facility: A facility that provides common services and/or functionalities for BSA 
execution. Examples of the application support facilities are CA basic service and DEN basic service. 
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Information support facility: A facility that provides common data and database management functionalities 
for BSA execution. Examples of the information support facilities are Local Dynamic Map (LDM) and map 
data base. 

Communication support facility: A facility that provides services for communications and session 
management. Examples of the communication support facilities are addressing mode, geocasting support and 
session support. 

Management facility: A facility that is interconnected with management or with security entity of the ITS-S. 



Facilities 
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Domain Facilities 



Application support 
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Figure 5.5: Facilities layer functional architecture 

As represented in figure 5.5: four Service Access Points (SAP) are connected to the facilities layer: 

• The FA-SAP (Facilities/ Applications - Service Access Point): A SAP that enables the full duplex exchange of 
data between the applications layer and the facilities layer. 

• The SF-SAP (Security/Facilities - Service Access Point): A SAP that enables the full duplex exchange of data 
between the facilities layer and the security. For example, the facility layer may request the security layer for 
certification of transmitted messages and the authentication of received messages. 

• The MF-SAP (Management/Facilities - Service Access Point): A SAP that enables the full duplex exchange of 
data between the facilities layer and the management layer. For example, the management layer will 
communicate to the facilities layer the applicable management policies to optimize the global system operation 
of the ITS-S and a consistent cross layer operation. 

• The NF-SAP (Network - Transport/Facilities - Service Access Point): A SAP that enables the full duplex 
exchange of data between the facilities layer and the network - transport layer. 

NOTE: The detailed specifications of the SAPs are out of the scope of the present document. 



5.3 



List of facilities 



Based on BSA functional requirements as provided in [i.2], a set of facilities are identified. The common facilities are 
listed in table 5.1, the domain facilities are listed in table 5.2. The present document provides functional descriptions for 
each of the facilities listed in table 5.1 and table 5.2, as well as the interactions with other facilities or with other layers 
of the ITS-S as defined in [1]. 

NOTE 1 : The present document does not make judgement whether a facility needs to be standardized. Some 
facilities may be proprietary and implemented depending to the development strategies of industries. 

NOTE 2: The present document does not specify any implementation architecture of the ITS-S facilities layer. In 
one possible implementation, a facility may be grouped with other facilities into one component, or may 
be implemented into multiple components. 
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The list of the common faciUties is given in table 5.1. Detailed functional specifications of each common facility are 
provided in clause 6 of the present document. 

Table 5.1 : List of common facilities 



Classification 


Identifier 


Facility name 


Short description 


IVIanagement 


CF001 


Traffic class management 


Manage assignment of traffic class value for the higher 
layer messages. 


CF002 


ITS-S ID management 


Manage ITS-S identifiers used by the application and the 
facilities layer. 


CF003 


AID management 


Manage the application ID used by the application and 
the facilities layer. 


CF004 


Security access 


Deal with the data exchanged between the application 
and facilities layer with the security entity. 


Application 
support 


CF005 


HMI support 


Support the data exchanges between the applications 
and HMI devices. 


CF006 


Time service 


Provide time information and time synchronization 
service within the ITS-S. 


CF007 


Application/facilities status 
management 


Manage and monitor the functioning of active 
applications and facilities within the ITS-S and the 
configuration. 


CF008 


SAM processing 


Support the service management of the management 
layer for the transmission and receiving of the service 
announcement message (SAM). 


Information 
support 


CF009 


Station type/capabilities 


Manage the ITS-S type and capabilities information. 


CF010 


ITS-S positioning service 


Calculate the real time ITS-S position and provides the 
information to the facilities and applications layers. 


CF011 


Location referencing 


Calculate the location referencing information and 
provide the location referencing data to the 
applications/facilities layer. 


CF012 


Common data dictionary 


Data dictionary for messages. 


CF013 


Data presentation 


Message encoding/decoding support. 


Communication 
support 


CF014 


Addressing mode 


Select addressing mode for messages transmission 


CF015 


Congestion control 


Facilities layer decentralized congestion control 
functionalities. 
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The list of the domain faciUties is given in table 5.2. Detailed functional specifications of each common facility are 
provided in clause 7 of the present document. 

Table 5.2: List of domain facilities 



Classification 


Identifier 


Facility name 


Short description 


Application 
support 


DF001 


DEN basic service 


Support the protocol processing of the Decentralized 
Environmental Notification Message. 


DF002 


CA basic service 


Support the protocol processing of the Cooperative 
Awareness Message. 


DF003 


EFCD 


Aggregation of CAM/DENM data at the road side ITS-S 
and provide to the central ITS-S. 


DF004 


Billing and payment 


Provide service access to billing and payment service 
provider. 


DF005 


SPAT basic service 


Support the protocol processing of the Signal Phase and 
Timing Message. 


DF006 


TOPO basic service 


Support the protocol processing of the Road Topology 
Message. 


DF007 


IVS basic service 


Support the protocol processing of the In Vehicle 
Signage Message. 


DF008 


Community service user 
management 


Manage the user information of a service community. 


Information 
support 


DF009 


Local dynamic map 


Local Dynamic Map database and management of the 
database. 


DF010 


RSU management and 
communication 


Manage the RSUs from the central ITS-S and 
communication between the central ITS-S and road side 
ITS. 


DF011 


Map service 


Provide map matching functionality. 


Communication 
support 


DF012 


Session support 


Support session establishment, maintenance and 
closure. 


DF013 


Web service support 


High layer protocol for web connection, SOA application 
protocol support. 


DF014 


Messaging support 


Manage ITS services messages based on message 
priority and client services/use case requirements. 


DF015 


E2E Geocasting 


Deal with the disseminating of information to ITS 
vehicular and personal ITS stations based on their 
presence in a specified Geographical area. 



6 Common facilities functional requirements 

Common facilities are facilities that are required by the operation of the ITS-S and/or provide support for 
communication interoperability. Moreover, certain common facilities provide cross layer information to the 
management and the security entities as defined in [1], therefore, these common facilities are management facilities. 

For the usage in the present document, each common facility is assigned with a unique number CF#, as illustrated in 
table 5.1. For each facility, a set of sub function and interfaces are defined. Each function is denoted by an identifier 
[CF#_F#] where CF# indicates the ID of the common facility; F# indicates the number of the function. Each interface is 
also denoted by an identifier [CF#_IN#] where CF# indicates the ID of the common facility, IN# indicates the number 
of the interface. 

For illustration purpose, a block diagram is defined for each common facility. This block diagram summarizes the main 
functionalities of the facility and logical connections with other facilities of the facilities layer and/or with other layers 
of the ITS-S, illustrated as external components in the block diagram. For simplicity reason, any external component if 
not referred as one of the facilities defined in the present document, the following external components are defined for 
illustration: 

• N&T: it corresponds to the ITS networking and transport layer as defined in [1]. 

• Management: it corresponds to the ITS management entity as defined in [1]. 

• Security: it corresponds to the ITS security entity as defined in [1]. 

• ITS application: it corresponds to the ITS application layer as defined in [1]. 
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• Messages: it corresponds to any facility that manages the faciUties layer or ITS application layer PDU, such as 
CA basic service, DEN basic service, etc. 

• Other external components as defined in corresponding facility. 

6.1 Management facilities functional requirements 
6.1 .1 CF001 : Traffic class management 

This facility deals with assignment of a traffic class value to each message transmitted by the applications and facilities 
layer of an ITS-S. The traffic class level is used by the management layer to select the appropriate communication 
protocol and access technologies to be used for the message transmission. Furthermore, the traffic class may also be 
used by the ITS networking and transport layer for the packet routing. 

The assignment of the traffic class is based on predefined rules and conditions. The parameters being taken into account 
for the assignment may be the message type, communication requirements, QoS requirements and the priority level of 
the application. The traffic class management facility implements conditions and policies to assign traffic class level to 
messages. 

The definition of traffic class and the assignment policies may be updated if required. If updates are required, the update 
information should be provided by an authorized entity of the application management, which may be implemented in 
an external system or in another ITS-S. 

The functional block diagram of the traffic class management common facility is illustrated in figure 6.1. 
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Figure 6.1 : Block diagram: Traffic Class Management 

The functional requirements of this common facility are presented in table 6.1: 

Table 6.1: Functional requirements: Traffic Class Management 



Functions 



Requirement 



[CF001_F1]: 



This function shall assign traffic class level to messages by implementing conditions and policies. 



[CF001_F2]: 



This function shall update the definition of the traffic class and the assignment policies if required by the 

application management authorities. 

This function is optional. 
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The interfaces of this common facility are presented in table 6.2: 



Table 6.2: Interfaces: Traffic Class Management 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF001_IN1] 


Application 


IN 


Data required for the traffic class assignment: 
e.g. communication requirements. 


[CF001_IN2] 


IVIessage 


IN 


Data required for the traffic class assignment: 

e.g. communication requirements, message type, QoS 

requirements etc. 


[CF001_IN3] 


Networking and 
transport layer 


OUT 


Traffic class set for the message. 


[CF001 IN41 


Management entity 


OUT 


Traffic class set for the message. 


[CF001_IN5] 


Application 
management 
Authority (may be 
implemented in an 
external ITS-S) 


IN 


Update information for the traffic class definition or 

the traffic class assignment policies. 

This interface may be an external interface. 



6.1 .2 CF002: ITS-S ID management 

This facility manages the identifier of an ITS-S being used within the application and facilities layer of the ITS-S. 

The identifier of an ITS-S shall allow unambiguous identification of an ITS-S from other ITS-S s in the network. Given 
the security and privacy protection requirements as identified in [i.5], this ITS-S ID may be a temporary pseudonym. 
The ITS-S ID management shall include functionality to update the ITS-S ID. It may be updated periodically by the 
security entity of the ITS-S. For this purpose, the ITS-S should be able to connect to the security infrastructure in order 
to update the ITS-S ID. 

Different ITS applications may have different requirements to identify an ITS-S from other ITS-Ss, an ITS-S ID is 
defined to satisfy these requirements. The ITS-S ID management facility interfaces with the security entity in order to 
ensure that the application requirements are provided to the security entity of the ITS-S. The ITS-S ID may be included 
in a message if required. 

The functional block diagram of the ITS-S ID management facility is given in figure 6.2. 
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Figure 6.2: Block diagram: ITS-S ID management 

The functional requirements of this common facility are presented in table 6.3: 

Table 6.3: Functional requirements: Traffic Class Management 



Functions 


Requirement 


[CF002_F1]: 


This function shall update the ITS-S ID for the usage of ITS applications and facilities layer, in 
connection with the security entity. 


[CF002_F21: 


This function shall discard the outdated ITS-S ID. 
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The interfaces of this common facility are presented in table 6.4: 

Table 6.4: Interfaces: ITS-S ID Management 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF002_IN1] 


Security entity 


IN/OUT 


OUT: Requirements for the ITS-S ID assignment. 

IN: Updated ITS-S ID to be used by the ITS applications 

and the facilities layer. 


[CF002_IN2] 


IVlessage or 
Applications 


IN/OUT 


OUT: Updated ITS-S ID to be used by the ITS applications 

and the facilities layer. 

IN: Requirements for the ITS-S ID assignment. 



6.1 .3 CF003: AID Management 



This common facility manages the Application Identifier (AID) being used within the application and facilities layer. 
An AID is the identifier of a message or the identifier of an ITS application. An AID can be updated and new AIDs can 
be added if the ITS-S is informed by an authorized application management entity which may be implemented in 
another ITS-S. An AID shall allow unambiguous identification of one ITS application or messages from other ITS 
applications and from other message. The assignment of an AID is based on regulatory and management rules that are 
defined by the authorized ITS application management entity. 

The functional block diagram of the AID management common facility is illustrated in figure 6.3. 
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Figure 6.3: Block diagram: AID management 

The functional requirements of this common facility are presented in table 6.5. 

Table 6.5: Functional requirements: AID management 



Functions 


Requirement 


[CF003_F1]: 


This function shall set an AID to an applications and/or a message that allows the unambiguous 
identification of an ITS application or a message from other ITS applications and from other message. 


[CF003_F2]: 


This function shall update the AID when necessary, as informed by the application management entity. 
This sub function is optional. 


[CF003_F3]: 


This function shall discard the invalid AIDs. 
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The interfaces of this common facility are presented in table 6.6. 



Table 6.6:lnterfaces: AID Management 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF003_IN1] 


Applications or 
messages. 


IN/OUT 


IN: Requirements for the AID assignment. 
OUT: The AID of the application. 


[CF003 IN2] 


Management layer 


OUT 


The AID that may be useful in the management layer. 


[CF003_IN3] 


Application 
management 
authorities (may be 
implemented in 
another ITS-S) 


IN 


The update information of the AID. This interface may be an 
external interface. 



6. 1 .4 CF004: Security access 

This common facility enables the data exchanges between the applications, the facilities layer and the security entity of 
the ITS-S. It provides the transmitted and received message or the application data to the appropriate security 
mechanism in the security entity that will process the message or data accordingly. Depending to the application 
requirements and the potential risks, different security mechanisms can be used to protect the messages and the data of 
the applications and the facilities layer. The decision on which security and protection actions to be used may be taken 
by the security entity or alternatively by the security access facility. 

Furthermore, the application and the facilities layer may require certain security reports from the security entity, in 
order to be informed of the malfunctioning or the security events of the ITS-S. 

The functional block diagram of the common facility is illustrated in figure 6.4. 
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Figure 6.4: Block diagram: Security access 

The functional requirements of this common facility are presented in table 6.7. 

Table 6.7: Functional requirements: Security access 



Functions 


Description 


[CF004_F1]: 


This function shall forward the message to the security for security processing, if applicable. 
Furthermore, this function may select the appropriate security and privacy protection mechanism for 
the transmitted and received message. 


[CF004_F2]: 


This function exchanges with the security in order to receive security events notifications as required 
by the applications. It shall be able to receive the information from the security entity and provide 
them to the applications or the facilities requesting such information. 
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The interfaces of this common facility are presented in table 6.8. 

Table 6.8: Interfaces: Security access 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF004_IN1] 


Application or 
IVIessages 


IN/OUT 


IN: IVIessage and security related primitives. 
OUT: Secured message. 


[CF004_IN2] 


Security 


IN/OUT 


OUT: Message and security related primitives, requests of 

security events notifications. 

IN: Secured message, security events notifications. 



6.2 Application support facilities functional requirements 
6.2.1 CF005: HMI support 

This common facility provides gateway function between the ITS applications and the Human Machine Interface (HMI) 
devices equipped by an ITS-S. It enables the dispatching of the application information to the HMI devices. One or 
more ITS applications active in the ITS-S send application processing results to the HMI devices through this common 
facility. According to the ITS application needs and the properties of the HMI device, one directional or duplex 
information exchange may be required. 

The HMI support common facility may statically or dynamically manage the information in the order of priority e.g. the 
emergency level of the information (e.g. collision risk warning, information on the traffic status) and/or the validity 
time of the information. 

In order to manage the communication between the ITS-S and HMI devices, the HMI support maintains a list of 
available HMI devices equipped by the ITS-S. Information included in this list may include the type of HMI device, the 
type of interface being used by the HMI device, and/or the availability of the HMI device, etc. 

The functional block diagram of the AID management is illustrated in figure 6.5. 
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Figure 6.5: Block diagram: HMI support 

The functional requirements of this common facility are presented in table 6.9. 

Table 6.9: Functional requirements: HMI support 



Functions 



Requirement 



[CF005_F1] 



This function shall receive data from ITS application or by the HMI device (HMI related data). 



[CF005_F2] 



This function shall manage the HMI related data with a predefined policy e.g. priority levels. 



[CF005_F3] 



This function shall send information to the ITS application or to the HMI device, when necessary. 



[CF005_F4] 



This function may keep the information of the HMI devices equipped by the ITS-S. 
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The interfaces of this common facility are presented in table 6.10. 

Table 6.10: Interfaces: HMI support 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF005_IN1] 


Application layer. 


OUT/IN 


Application processing results or the information sent from the 
HMI device. 


[CF005_IN2] 


HMI device 


OUT/IN 


Application processing results or the information sent from the 
HMI device. 



6.2.3 CF006: Time service 

This common facility provides support for dealing with time and time synchronization for all available time stamped 
data being used within message and ITS applications. A common unified and standardized time reference is defined and 
used for all ITS-Ss. Referring to this common ITS time definition, different time stamps may be defined in different 
message, depending on the validity time and time granularity requirement of that message. For the messages being 
defined for the BSA, the International Atomic Time (TAI) is used as the common time reference. The time stamp 
definition of each message is specified specifically by each message standard. 

The time service shall include a functionality to synchronize the time to the standardized TAI time. Different time 
augmentation data sources can be used for such synchronization, e.g. satellite based time augmentation, ground based 
time augmentation, etc. In case of non-synchronization, a time correction shall be applied. 

The functional block diagram of the time service common facility is illustrated in figure 6.6. 
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Figure 6.6: Block diagram: Time service 

The functional requirements of this common facility are presented in table 6.11. 

Table 6.11 : Functional requirements: Time service 



Functions 


Requirement 


[CF006_F1]: 


This function shall execute the time synchronization to the TAI time with the time 
augmentation source when necessary. 


[CF006 F21: 


This function shall execute the time correction in case of non-synchronization. 


[CF006 F3]: 


This function shall provide the time information to the required messages and applications. 
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The interfaces of this common facility are presented in table 6.12. 



Table 6.12: Interfaces: Time service 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF006_IN1] 


Time augmentation 

data e.g. satellite based time 

correction (may be 

implemented in an external 

system). 


IN 


Time augmentation data provided by the time 
augmentation source, this interface may be an external 
interface. 


[CF006_IN2] 


message facilities and/or 
applications. 


OUT/IN 


OUT: Time information. 

IN: Request of time information if necessary. 



6.2.4 CF007: Application/facilities status management 

This common facility manages a list of available applications and facilities in the ITS-S. It also keeps the corresponding 
configuration information for each ITS application and facility. This common facility also monitors the functioning 
status of the applications and facilities of the ITS-S. In case of the malfunction of an application or a facility, this 
common facility may notify the related applications/facilities or to the user of the malfunctioning. 

Optionally, this common facility manages the ITS-S applications life cycle through downloading of new customer 
applications, up-grading or removing of existing applications. If the update of one application can be done remotely, 
services provisioning servers advertise the availability of new services which can be contracted/downloaded by ITS-S 
via the service announcement message (SAM). In a receiving ITS-S, the service management component of the 
management layer analyses the received SAM. The application layer, after a local dialogue with the user if necessary or 
based on pre-defined strategies, identifies the applications to be installed or updated. Then, the downloading of selected 
application software and associated data are achieved by the ITS-S which initiates a communication session with the 
service provisioning servers. Such downloading operation will lead to an updating of the information managed by the 
application management common facility. 

The functional block diagram of the Application/facilities status management common facility is illustrated in 
figure 6.7. 
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Figure 6.7: Block diagram: Application/facilities status management 

The functional requirements of this common facility are presented in table 6.13. 

Table 6.13: Functional requirements: Application/facilities status management 



Functions Requirement 


[CF007_F1]: 


This function shall maintain a list of available applications and facilities being activated in an 
ITS-S. It shall also monitor the functioning status of the application and facilities. 
The list of available applications and facilities may be extended and updated. 


[CF007_F2]: 


This function shall updates an application/facilities and their corresponding configuration 
provided by the application provisioning services, either from a local connection or remotely. 
This function is optional. 


[CF007_F3]: 


This function shall download new applications and facilities provided by the application 
provisioning services, either from a local connection or remotely. 
This function is optional. 


[CF007_F4]: 


This function shall configure the application, its related facilities and interfaces at the start up or 
updates of the applications and facilities. 
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The interfaces of this common facility are presented in table 6.14. 

Table 6.14: Interfaces: Application/facilities status management 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF007 IN1] 


Application/facilities/management 


IN/OUT 


Configuration data updates information. 


[CF007_IN2] 


Application provisioning service 


IN 


Data for the updates of an application and/or 
facilities, or data for the downloading of new 
application and/or new facilities. 
This interface may be an external interface. 



6.2.5 CF008: Service announcement message (SAM) processing 

This common facility supports the service management function of the management layer as specified in [i.4], it 
constructs and transmits the service announcement message (SAM) at the request of the ITS-S management layer, in 
order to announce the available user services as well as the communication access technology being used to access to 
the service. The SAM includes information of the provided service, the communication access technologies and other 
information that enables the access to the services. When the service management component in the management layer 
needs to send a SAM, it provides the SAM content data to the SAM processing facility which constructs a 
corresponding SAM and transmits it to the ITS networking and transport layer. 

For a received SAM the SAM processing facility decodes the received SAM and provides the data to the management 
layer, which communicates with the corresponding applications in order to decide whether the service is interested by 
the ITS-S and/or users. 

The functional block diagram of this common facility is illustrated in figure 6.8. 
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Figure 6.8: Block diagram: SAM processing 

The functional requirements of this common facility are presented in table 6.15. 

Table 6.15: Functional requirements: SAM processing 



Functions 


Requirement 


[CF008_F1]: 


This function shall execute the SAM transmission protocol under the request from 
management entity. 


[CF008_F2]: 


This function shall execute the SAM reception protocol and provide the content of the received 
SAM to the management layer. 
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The interfaces of this common facility are presented in table 6.16. 



Table 6.16: Interfaces: SAM processing 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF008_IN1] 


Service management 
of the management 
entity 


IN/OUT 


IN: Request to construct a SAM and the content of the 

message. 

OUT (to service management): content of the received 

SAM. 


[CF008_IN2] 


Data presentation 


IN/OUT 


Import the data presentation from the common data 
dictionary and message encoding/decoding support. 


[CF008 INS] 


Security access 


IN/OUT 


SAM (sent and received) for security processing. 


[CF008_IN4] 


N&T 


IN/OUT 


OUT: SAM delivered to the ITS networking and 
transport layer for transmission. 
IN: SAM received from the ITS networking and 
transport layer. 



6.3 Information support facilities functional requirements 
6.3.1 CF009: Station type/capabilities 

This common facility provides information to describe a profile of an ITS-S to be used in the applications and the 
facilities layer, in particular: 

• The ITS-S type: vehicle ITS-S, road side ITS-S, personal ITS-S or central ITS-S. 

• The role that is currently played by the ITS-S: operation status of an emergency vehicle and other prioritized 
vehicle, status of a dangerous goods transporting vehicle, etc. 

• Detection capabilities and status e.g. positioning capability, sensing capabilities, etc. of the ITS-S. For the 
vehicle ITS-S, this common facility collects the in vehicle data from the in vehicle data gateway including the 
highly dynamic vehicle mobility information and the status of the in vehicle electronic systems; For the road 
side ITS-S, this common facility may receive from the road side equipment data gateway the real time road 
side sensor information and the equipment status information; For the central ITS-S, the capabilities 
information may refer to the controls means of an central ITS-S in order to control the road side equipment 
remotely e.g. centralized traffic light controllers. Variable Message sign, road side sensors, etc. 

Each application may have its own specific requirements on the ITS-S station type, roles and capabilities in order to 
enable the application running. The same ITS-S may play different roles in different applications. For example, a 
moving road construction vehicle may be considered as a road side ITS-S in roadwork warning application, while in a 
forward collision warning application, it may be considered as a vehicle ITS-S. Furthermore, different applications may 
have different requirements to the capabilities, in order to ensure the required data quality. For example, the positioning 
accuracy is one of most important requirement for road safety applications. 

It should be noted that station type/capabilities information may be dynamic and vary over space and over time. An 
example of such dynamism is that when personal ITS-S is located within a vehicle, it may be considered as a vehicle 
ITS-S under some conditions and participates to certain ITS applications as the vehicle ITS-S. Another example is that 
when a vehicle enters a tunnel, the position accuracy level may be reduced due to the loss of the satellite signal. 
Therefore, this common facility shall include functionality to monitor the status of the ITS-S and connected sensors. 

An ITS-S should satisfy the specific requirements in order to be used as that station type in that specific application. 
These requirements can be security requirements, detection capacities, performance requirements, operational 
requirements or other requirements. 

Furthermore, this common facility may also include a functionality to monitor the station status and detects abnormal 
station failures. It provides station state of the ITS-S and if available the status information of equipped sensors. For 
example, the sensor status information may be used to define the reliability level of the detected road hazard by an 
ITS-S application. 
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The functional block diagram of the common facility is illustrated in figure 6.9. 
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Figure 6.9: Block diagram: Station type/capabilities 

The functional requirements of this common facility are presented in table 6.17. 

Table 6.17: Functional requirements: Station type/capabilities 



Functions 


Requirement 


[CF009_F1]: 


This function shall update the station type/capacities information when necessary. It shall provide 
the relevant information of the station type/capacities to the applications and the facilities. 


[CF009_F2]: 


This function shall notify the failure and malfunctioning of the sensors or station type information 
to the applications and the facilities, either automatically when the failure is detected or under the 
request of the applications/facilities. 


[CF009 F3]: 


This function shall monitor the status and changes of the station type/capacities. 



The interfaces of this common facility are presented in table 6.18. 



Table 6.18: Interfaces: Station type/capabilities 



Interface 



Related component 



Direction 



Information exchanged over the interface 



[CF009_IN1] 



Application, 
message, other 
facilities 



OUT 



Station type/capacities information as needed for the 
facilities and applications. 



Connected and 
equipped sensors of 
the ITS-S; in vehicle 
data gateway; road 
equipment data 
gateway. 



[CF009_IN2] 



IN 



Sensors status information. 



6.3.2 CF01 0: ITS-S positioning service 



This common facility provides and updates the geographical positioning of an ITS-S in real time. Different technologies 
can be used to determine in real time the geographic position, with variable accuracy level. The Global Navigation 
Satellite System (GNSS) may be used as primary positioning means in the ITS co-operative system, in particular for the 
mobile ITS-Ss. The position accuracy and freshness is one of the key requirement for the road safety ITS applications. 
For example, the CA basic service requires that the positioning information of a vehicle ITS-S is able to be updated at 
high frequency e.g. 10 Hz. When the GNSS signal is not available or when GNSS position accuracy is not sufficient for 
the applications, some positioning augmentation technologies can be used to provide other information and data for the 
position augmentation, such as satellite based positioning augmentation (e.g. EGNOS) and ground based positioning 
augmentation (e.g. DGPS). For vehicle ITS-S, in vehicle sensor data may also be used to further improve the 
positioning accuracy information, e.g. the vehicle speed, vehicle heading, etc. A data fusion function can be used to fuse 
the data from different augmentation sources and obtain an increased accuracy and integrity information of the position. 
The ITS-S positioning facility also provides speed and heading information of the ITS-S in mobility. All above 
information is provided together with an accuracy level. Optionally, the ITS-S position may also be provided with 
integrity information, when required by an ITS application. 
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The functional block diagram of the common facility is illustrated in figure 6.10. 
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Figure 6.10: Block diagram: ITS-S positioning service 

The functional requirements of this common facility are presented in table 6.19. 

Table 6.19: Functional requirements: ITS-S positioning service 



Functions 


Description 


[CF010_F1]: 


This function shall calculate the ITS-S positioning in real time from the GNSS receiver or from a 
positioning system. When applicable, this functionality shall also calculate the speed and direction 
information of the ITS-S. 


[CF010_F2]: 


This function shall augment the position and velocity information based on the received ground based 
augmentation data. 
This function is optional. 


[CF010_F3]: 


This function shall augment the position and velocity information with the in-vehicle data or other 
sensors data connected to the ITS-S. 
This function is optional. 


[CF010_F4]: 


This function shall augment the position and velocity information based on the received satellite 
based augmentation data. 
This function is optional. 


[CF010_F5]: 


This function shall fuse the data of multiple augmentations and calculate a final position and related 
accuracy of the ITS-S. 


[CF010_F6]: 


This function shall check the integrity of the position and velocity information when required. 
This function is optional. 
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The interfaces of this common facility are presented in table 6.20. 



Table 6.20: Interfaces: ITS-S positioning service 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF010_IN1] 


GNSS receiver or other 
positioning means 


IN 


Positioning information as received from the 
GNSS receiver or other positioning means. 


[CF010_IN2] 


Station type/capabilities 


IN 


In vehicle data or other sensor information for 
the position augmentation. 


[CF010_IN3] 


Ground based augmentation 
data 


IN 


Data for the position augmentation sent from the 

ground based positioning augmentation service 

provider. 

This interface may be an external interface. 


[CF010_IN4] 


Satellite based augmentation 
data 


IN 


Data for the position augmentation sent from the 

satellite based positioning augmentation service 

provider. 

This interface may be an external interface. 


[CF010_IN5] 


Message; Application or 
other facilities 


OUT 


Position, speed, heading information, the 
accuracy and/or the integrity information. 



6.3.3 CF01 1 : Location referencing 

This common facility provides location referencing information of a geographic location that allows the association of a 
geographical location with regards to road network and surrounding environment. Depending on the application 
requirement(s), the information needed for location referencing may vary in different levels of detail and levels of 
geographical extensions. 

Multiple location referencing methodologies are available in ITS, e.g. TMC-LOC, ALERT-C, TPEG-LOC, etc. For 
interoperability purpose, a common location referencing definition and coding rule should be used by all ITS-Ss 
implementing the same sets of message protocols. For example for the DENM protocol as specified in [3], the "trace" 
location referencing is used. This location referencing provides a list of waypoint coordinates, along which the receiver 
ITS-S may encounter the event as informed by DENM. This location referencing allows different ITS-Ss receiving the 
DENM to reference the event position regardless of different map formats being used in the ITS-S and verify the 
relevance of the information to the receiving ITS-S. 

This conmion facility generates the location referencing data as required by the application, according to the application 
requirements. Optionally, this common facility may be implemented at the applications layer. 

The functional block diagram of the common facility is illustrated in figure 6.1 1. 
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Figure 6.11: Block diagram: Location Referencing 



ETSI 



30 



ETSI TS 102 894-1 VI. 1.1 (2013-08) 



The functional requirements of this common facility are presented in table 6.21. 

Table 6.21: Functional requirements: Location Referencing 



Functions 


Requirement 


[CF011_F1]: 


This function shall collect required data from other facilities and/or from applications for the 

calculation of the location referencing information. 

In particular, this function may receive request and requirements from the applications for the 

calculation of the location referencing. It may further interact with the station positioning management 

in order to obtain the current position of ITS-S if needed. 

This function may need to consult the map data base in order to calculate the location referencing 

data. 


[CF011_F2]: 


This function elaborates the location referencing data and provides them for the applications and 
facilities usage. In particular, it shall provide the information to the message, if the location 
referencing information is required to be included within the message e.g. DENM. 



The interfaces of this common facility are presented in table 6.22. 



Table 6.22: Interfaces: Location Referencing 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF011_IN1] 


Map service 


IN/OUT 


Map database information used for the location referencing 
if the digital map is needed for the location referencing 
calculation. 


[CF011_IN2] 


Station positioning 
management 


IN 


ITS-S current position and velocity information. 


[CF011_IN3] 


Application 


IN 


Request of application and application requirements for the 
details and extensions of location referencing. 


[CF011_IN4] 


Message, 

applications, LDM or 
other facilities 


OUT 


Location referencing data as included in the message or 
needed by the applications and/or other facilities. 



6.3.4 CF01 2: Common data dictionary 

This common facility manages a common data dictionary for data elements being commonly used in the messages 
and/or by the ITS applications and facilities e.g. vehicle data, position data, time, location referencing data, road 
topology data, traffic regulation data, etc. The data dictionary may be organized in multiple classes depending to the 
type and source of the data. When new applications and messages are included in the ITS-S including new data, this 
data dictionary may be extended. 

The functional block diagram of the basic facility is illustrated in figure 6.12. 
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Figure 6.12: Block diagram: Data dictionary 
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The functional requirements of this common facility are presented in table 6.23. 

Table 6.23: Functional requirements: Data dictionary 



Functions 


Requirement 


[CF012_F1]: 


This function shall maintain the list of data elements and data frames definition in the data 
dictionary. 


[CF012_F2]: 


This function shall update the data dictionary to include modification of exiting data elements/data 
frames or new data elements/data frames. 



The interfaces of this common facility are presented in table 6.24. 

Table 6.24: Interfaces: Data dictionary 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF012_IN1] 


Applications, 
Messages, facilities 


IN/OUT 


IN: Update information. 

OUT: Data definition being used in the applications and/or 

in the facilities layer. 


[CF012 IN2] 


Data presentation 


IN/OUT 


Data elements syntax for data presentation. 



6.3.5 CF01 3: Data presentation 



This common facility provides encoding/decoding support for messages being exchanged between ITS-Ss and data 
exchanged within an ITS-S. The data presentation is based on the common data dictionary contained in the ITS-S. It 
formats or encrypts a messages with standardized syntax and semantics representations before transmitting the message 
payload to the ITS networking and transport layer. At the receiving side, this common facility provides supports to the 
corresponding facilities during the decoding of the message payload. 

For messages CAM and DENM as specified in [2] and [3], ASN.l unaligned PER encoding rules shall be used. For 
other applications, other formats such as XER may be used, for example for messages exchanged between road side 
ITS-S and central ITS-S and between two central ITS-Ss (e.g. DATEX II). If required for the data exchanged within the 
ITS-S, this common facility may also provide the encoding/decoding support. 

The data presentation facility is interacting with data dictionary for the encoding and decoding of messages. 

The functional block diagram of the common facility is illustrated in figure 6.13. 
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Figure 6.13: Block diagram: Data presentation 
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The functional requirements of this common facility are presented in table 6.25. 



Table 6.25: Functional requirements: Data presentation 



Functions 



Requirement 



[CF013_F1] 



This function shall provide compiling functions for the encoding of message based on PER rules. 



[CF013_F2] 



This function shall provide compiling functions for the decoding of message based on PER rules. 



[CF013_F3] 



This function shall provide compiling functions for the encoding of message based on XER rules. 



[CF013_F4] 



This function shall provide compiling functions for the decoding of message based on XER rules. 



The interfaces of this common facility are presented in table 6.26. 



Table 6.26: Interfaces: Data presentation 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF013 IN1] 


Message 


IN/OUT 


Data for the encoding and decoding of the messages. 


[CF013 IN2] 


Data dictionary 


IN 


Data definition required for the encoding and decoding. 



6.4 Communication support facilities functional requirements 
6.4.1 CF014: Addressing mode 

This common facility determines the addressing mode for messages that need to be transmitted from the ITS-S 
according to the dissemination destination as required by the messages. Depending on the use case requirements as 
defined in the BSA [i.l], dissemination destination of a message may be: 

a geographic area; 

ITS-S s with specific network address; 

ITS-Ss with specific IDs; 

ITS-S s bearing specific user profiles; or 

ITS-Ss with combinations of some of above descriptions. 

For each of the destination type, information provided from the addressing mode facility to the ITS networking and 
transport layer shall allow receivers to reconstruct the destination area for relevance checks. Standardized description 
method needs to be defined in order to ensure the interoperability. The addressing mode facility shall provide the 
destination information to the ITS networking and transport layer as compliant to the information being used by the ITS 
networking and transport layer protocol. In case that the destination information provided by the application is not 
compliant to the ITS networking and transport layer destination area description, the addressing mode facility shall 
include a functionality to convert to the data as required by the ITS networking and transport layer. 

Furthermore, addressing mode shall determine the dissemination mode being used by the ITS networking and transport 
layer protocol, such as point to point, point to multi point. 

All above addressing mode information shall be provided to the ITS networking and transport layer via the NF-SAP. If 
required, it shall provide other data required by the ITS networking and transport layer, e.g. the traffic class of the 
message, the transmission interval, etc. 

The above mentioned data may be provided to the management layer, which selects the appropriate communication 
protocol stack for the communication. 
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The functional block diagram of the common facility is illustrated in figure 6.14. 
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Figure 6.14: Block diagram: Addressing mode 

The functional requirements of this common facility are presented in table 6.27. 

Table 6.27: Functional requirements: Addressing mode 



Functions 


Description 


[CF014 F1]: 


This function shall determine the destination information for a message. 


[CF014 F2]: 


This function shall determine the dissemination mode for a message. 


[CF014 F3]: 


This function shall provide access to the Networking and Transport layer and provide the data of 
the destination, the dissemination mode as well as related data. 



The interfaces of this common facility are presented in table 6.28. 

Table 6.28: Interfaces: Addressing mode 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF014_IN1] 


Message; traffic 
class management 


IN 


Destination and dissemination mode of the message, traffic 
class of the message. 


[CF014_IN2] 


N&T 


OUT 


Data required by the ITS N&T layer for the message 
dissemination. 


[CF014_IN3] 


Management 


IN/OUT 


Data required by the management entity and data provided 
by the management entity. 



6.4.2 CF015: Congestion control 



The common facility includes the decentralized congestion control (DCC) functionalities of the facilities layer. It 
interacts with the management entity and contributes to the overall ITS-S congestion control functionalities. Various 
methods may be used at the facilities and applications layer for reducing at the number of generated messages based on 
the congestion level. Among them following methods may be used: 

• To adjust the message transmission interval in order to reduce the number of messages sent to the network. An 
ITS application may have specific requirements of the message transmission frequency. The DCC of the 
facilities layer should take into account the application requirements. 
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• To control the re-forwarding of the messages within the congestion situation. As specified in DEN basic 
service [3], a facihties layer keep-alive function may be used to forward a received DENM within an area and 
within a validity time, in order to maintain the DENM dissemination in case that the originator transmitting 
ITS-S has lost the capacity of transmission in an unexpected manner. According to the congestion level, the 
DCC of the facilities layer may deactivate this facilities layer forwarding functionality. 

• To aggregates the received messages during the forwarding. If multiple messages generated by different 
ITS-S s are duplicating with other others, the ITS applications or facilities may aggregate the duplicate message 
and keep the most updated or reliable messages for the forwarding. This function (referred as Information 
Centric Forwarding) may reduce the number of messages transmitted and forwarded within the ITS network. 

The DCC at the facilities layer may interact with the DCC functionalities of other layers in order to take appropriate 
actions according to the congestion level and to satisfy the application requirements. The DCC common facilities shall 
receive from the management entity the congestion status information of the ITS networks, and accordingly select an 
appropriate DCC mechanism for the message transmission and forwarding. 

The functional block diagram of the common facility is illustrated in figure 6.15. 

NOTE: The indicated functions are provided as example. 
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Figure 6.15: Block diagram: Congestion control 

The functional requirements of this common facility are presented in table 6.29. 

Table 6.29: Functional requirements: Congestion control 



Functions 


Requirement 


[CF015_F1]: 


This function shall adjust the message transmission frequency for the applications and facilities layer 

messages. 

It may apply to a specific message transmission under predefined rules of the DCC. 


[CF015_F2]: 


This function shall execute the keep alive functionality of messages. 

It may apply to a specific message transmission under predefined rules of the DCC. 


[CF015_F3]: 


This function shall execute the information centric forwarding function for messages. 
It may apply to a specific message transmission under predefined rules of the DCC. 



The interfaces of this common facility are presented in table 6.30. 



Table 6.30: Interfaces: Congestion control 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[CF016_IN1] 


Message and 
applications 


IN/OUT 


IN: Data required by the DCC functionalities from the 
messages e.g. requirements, traffic class, etc. 
OUT: Data related to the messages transmissions 
according to the applied DCC mechanism. 


[CF016_IN2] 


Management 


IN/OUT 


IN: Network congestion status and other cross layer data 
needed by the congestion control mechanism; 
OUT: Data required by the management layer. 
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7 Domain facilities functional requirements 

Domain facilities provide services and functionalities for one or several BSA applications or for one or several ITS-S 
types. A domain facilities may become optional for other ITS applications and other ITS-S types. 

For the usage in the present document, each domain facility is assigned with a unique number DF#, also illustrated in 
table 5.2. For each facility, a set of sub function and interfaces are defined. Each function is denoted by an identifier 
[DF#_F#] where DF# indicates the ID of the domain facility, F# indicates a sequence number of the function. Each 
interface is also denoted by an identifier [DF#_IN#] where DF# indicates the ID of the domain facility, IN# indicates a 
sequence number of the interface. 

For illustration purpose, a block diagram is defined for each domain facility. This block diagram summarizes the main 
functionalities of the facility and logical connections with other facilities of the facilities layer and/or with other layers 
of the ITS-S, illustrated as external components in the block diagram. For simplicity reason, any external component if 
not referred as one of the facilities defined in the present document, the following external components are defined for 
illustration: 

• N&T: it corresponds to the ITS networking and transport layer as defined in [1]. 

• Management: it corresponds to the ITS management entity as defined in [1]. 

• Security: it corresponds to the ITS security entity as defined in [1]. 

• ITS application: it corresponds to the ITS application layer as defined in [1]. 

• Messages: it corresponds to any facility that manages the facilities layer or ITS application layer PDU, such as 
CA basic service, DEN basic service, etc. 

• Other external components as defined in corresponding facility. 

7.1 Application support facilities functional requirements 
7.1.1 DF001 : DEN basic service 

This domain facility executes the Decentralized Environmental Notification Message (DENM) protocol and provides 
management support of DENMs. The DENM protocol is used mainly by the Cooperative Road Hazard Warning 
applications as defined in BSA [i.l] in order to inform a detected event on the roads to approaching vehicles and to road 
users. A DENM is originated by an ITS-S upon detection of an event. The application provides data about attributes of 
the detected event, e.g. event type, event duration, destination area of the DENM dissemination, etc. to the DEN basic 
service domain facility via an application request. The DEN basic service shall constructs a DENM as specified in [3] 
and sends the message as payload to the ITS networking and transport layer via the NF-SAP. 

Typically, a detected event is characterized by its position, an event type, and duration. An event may be evolving over 
space and over time. Therefore, the applications of the ITS-S may request to send updated DENMs in order to indicate 
the evolution and the termination of the event. Consequently, the DENM protocol shall include functions to construct 
updated DENMs as specified in [3]. 

At receiving side, the DENM protocol includes the discarding of outdated DENMs and optionally the keep alive 
function as mentioned in clause 6.4.2. The received event information is provided to ITS applications, either directly via 
an application programming interface (API) or via a common database (Local Dynamic Map). Due to the high mobility 
and the dynamics of the vehicle ITS-Ss, the originated ITS-S may either leave the originated position or lose the 
capacity to transmit DENM related to the events. An ITS-S may forward a DENM within the destination area as long as 
the DENM is still valid. For some applications, an ITS-S that triggers a DENM may be different from the ITS-S that 
informs the termination of the event, in case the ITS-S that triggered the DENM has left or have lost the capability 
itself. The DENM protocol shall support the above mentioned situations. 

DENM protocol shall be as specified in [3]. 
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The functional block diagram of the basic facility is illustrated in figure 7.1. 
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Figure 7.1 : Block diagram: DEN basic service 

The functional requirements of this domain facility are presented in table 7.1. 

Table 7.1: Functional requirements: DEN basic service 



Functions 


Requirement 


[DF001_F1]: 


This function shall execute the DENM transmission protocol. It constructs a DENM when receiving a 
request from application, and initiates the DENM transmission. The construction of the DENM shall 
be supported by the data presentation facility as specified in clause 6.2.5. The DENM format shall be 
as specified in [3]. 

The DENM transmission protocol shall include functionalities to enable the DENM initiation, DENM 
updates and DENM termination from originator ITS-S. 


[DF001_F2]: 


This function shall execute the DENM reception protocol. It decodes a received DENM, manages its 
life time according to a validity time and provides the DENM content to the applications and/or to the 
LDM when requested. 

The DENM reception protocol shall include functionalities to discard the outdated DENM and to 
provide the update DENM content to the ITS applications. 


[DF001_F3]: 


This function shall execute a "keep-alive function" as defined in clause 6.4.2 in order to maintain 
forwarding of a DENM which is still valid within a specific area and specific duration. 
This function is optional. 



The interfaces of this domain facility are presented in table 7.2. 



Table 7.2: Interfaces: Congestion control 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF001_IN1] 


Application; LDM or 
other facilities 


IN/OUT 


IN: Request from application for the transmission of new 

DENM, updated DENM or DENM termination, together with the 

data related to the detected event and the DENM dissemination 

requirements. 

OUT: Content of the received DENM. 


[DF001_IN2] 


Data presentation 


IN/OUT 


Data required for the DENM encoding/decoding, as supported 
by the data presentation common facility. 


[DF001_IN3] 


ITS networking and 
transport layer 


IN/OUT 


IN: Received DENM payload delivered from the N&T layer to 
the DEN basic service. 

OUT: DENM payload delivered from the DEN basic service to 
the N&T layer for DENM transmission. 


[DF001_IN4] 


LDM or other facilities 


OUT 


Content of the received DENM. 
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7.1 .2 DF002: CA basic service 

The Cooperative Awareness (CA) basic service is a facilities layer entity that provides functions for the management of 
the facilities layer heartbeat messages i.e. cooperative awareness messages (CAM). It operates the CAM protocol. In 
BSA, this common facility is relevant to vehicle ITS-S and road side ITS-S. It is expected that other ITS-S may transmit 
the CAM in the future. 

The CA basic service is in charge of constructing and transmitting CAM at a variable interval. For this purpose, the CA 
basic service interfaces with other facilities in order to collect required data for the CAM construction. For the received 
CAM, the CA basic service decodes the received CAMs and provides the received information to a facilities layer 
database Local Dynamic Map (LDM) and/or to the ITS application. The CAM is a heartbeat message of the facilities 
layer with a transmission interval varying between several hundred milliseconds to one second. This frequency may be 
adjusted according to the application requirements and/or the network congestion level. For this purpose, interfaces with 
the application and the management layer may be needed. 

The C A basic service shall be as specified in [2] . 

The functional block diagram of the CA basic service common facility is illustrated in figure 7.2. 
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Figure 7.2: Block diagram: CA basic service 

The functional requirements of this common facility are presented in table 7.3. 

Table 7.3: Functional requirements: CA basic service 



Functions 



Requirement 



[DF002_F1] 



This function shall collect data required to construct a CAM. The CAM format shall be as specified in [2]. 
This function shall manage the CAM transmission frequency according to the congestion level. 



[DF002_F2] 



[DF002_F3] 



This function shall operate the CAM originator protocol and transmit the CAM to the networking and 
transport layer. 



[DF002_F4]: 



This function shall operate the CAM receiver protocol and process the received CAMs. 
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The interfaces of this common facility are presented in table 7.4. 



Table 7.4: Interfaces: CAM basic service 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF002_IN1] 


Station type/capacities; 
AID management; 
Position and time 
management; 
ITS-S ID management; 


IN 


Data required for the construction of CAIVI: 

• Station type; 

• In vehicle data (for vehicle CAM); 

• AID information of CAM; 

• Current position and time information of the 
ITS-S; 

• ITS-S ID information; 

• Other information included in CAM as specified 
in [21. 


[DF002_IN2] 


Data presentation 


IN/OUT 


Data presentation and message encoding/decoding 
support. 


[DF002_IN3] 


N&T 


IN/OUT 


OUT: CAM delivered to Networking and Transport 
layer for transmission. 

IN: Received CAM delivered by the Networking and 
Transport layer. 


[DF002 IN41 


LDM 


OUT 


Content of the received CAMs to the LDM. 


[DF002_IN5] 


Application 


IN/OUT 


IN: Application requirements, if applicable. 
OUT: Content of the received CAMs to the LDM 
and/or to the application. 


[DF002_IN6] 


IVIanagement 


IN/OUT 


Data required by the management layer and/or 
information of the congestion level. 



7.1 .3 DF003: Extended vehicle floating car data (EFCD) 

This domain facility enables road side ITS-S, vehicle ITS-S or personal ITS-S to assist the road traffic management 
applications. Vehicle ITS-S or personal ITS-S transmits CAM periodically and DENM when a specific event is 
detected. These two messages contain information that may be useful for the traffic management. CAM and DENM 
may be transmitted to road operator, either directly from vehicle or via a road side ITS-S. CAM, DENM data provided 
by vehicle ITS-S can be considered as an extension of the Floating car data (FCD). Due to the large amount of the data 
being transmitted (e.g. CAM and DENM are transmitted at a high frequency varying from 0,5 Hz to 10 Hz), this 
domain facility may collect, aggregate the data before transmitting to road operator. As example, the road side ITS-S 
may calculate the average travel time based on the position and time data in received CAMs from vehicle ITS-S. Then 
the road side ITS-S transmit the aggregated travel time data to TMC using a specific message format such as DATEX II 
message [i.3]. 

This domain facility includes functionalities to collect the received messages, process the data into aggregated 
information and transmission of the aggregated information according to the needs of the traffic management. These 
needs (e.g. data to be provided, transmission interval of the data report) may be set by a central ITS-S. 

The functional block diagram of the basic facility is illustrated in figure 7.3. 
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Figure 7.3: Block diagram: EFCD 
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The functional requirements of this domain facility are presented in table 7.5. 

Table 7.5: Functional requirements: EFCD 



Functions 


Description 


[DF003_F1]: 


This function shall collect the CAM, DENM or other messages from mobile ITS-Ss. 

It may collect these data from the LDM which stores the received CAM, DENM information or directly 

from the messages. 


[DF003_F2]: 


This function shall process and aggregate the collected data, as required by the traffic management 
operator. 


[DF003_F3]: 


This function shall transmit the aggregated data to the central ITS-S via e.g. the DATEX II gateway, 
with a required frequency or upon request from the central ITS-S. 



The interfaces of this domain facility are presented in table 7.6. 

Table 7.6: Interfaces: Congestion control 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF003 IN1] 


LDM; messages 


IN 


Data received from mobile ITS-Ss via the messages. 


[DF003_IN2] 


Data presentation 


IN/OUT 


Data required for encoding of messages sent to the 
central ITS-S. 


[DF003_IN3] 


DATEX II gateway 


IN/OUT 


IN: Rules and requirements for data aggregation. 
OUT: Transmission of aggregated data in the format of 
e.g. DATEX II. 



7.1 .4 DF004: Billing and payment 

This domain facility is relevant for applications requiring billing and payment. It provides billing and payment 
functionality for services that require payment. This facility establishes connections with back end actors that operate, 
handle and confirm billing as required by the applications. In a possible implementation of ITS-S, the billing and 
payment services can be provided by a specific billing/payment application (probably already implemented in an 
existing system external to the ITS-S. This domain facility should provide an interface to this billing/payment 
application. If an interaction with client is required by the billing process, such as confirmation of the payment 
information, confirmation of the user identifier, etc. this domain facility may sends and receives data to the HMI 
support common facility, as defined in clause 6.2.1. 

Billing and payment requires high security and privacy protection, therefore, this domain facility shall have an interface 
to the security entity via the security access facility as defined in clause 6.1.4. 

The functional block diagram of this domain facility is illustrated in figure 7.4. 
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Figure 7.4: Block diagram: Billing and payment 
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The functional requirements of this domain facility are presented in table 7.7. 

Table 7.7: Functional requirements: Billing and payment 



Functions 


Requirement 


[DF004_F1]: 


This function shall interact with application in order to initiate, and to terminate the process of the 
billing and payment. 


[DF004_F2]: 


This function shall generate and transmit billing/payment messages as required by the ITS 
application. It shall manage the received messages regarding the billing/payment messages and 
provide the information to the application. 


[DF004 F3]: 


This function manages the user data required for the billing/payment. 



The interfaces of this domain facility are presented in table 7.8. 



Table 7.8: Interfaces: Billing and payment 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF004_IN1] 


Application 


IN/OUT 


Data exchanged with application for the initiation, management 
and termination of the billing/payment. 


[DF004_IN2] 


Back end system 


IN/OUT 


Communication with back end system for the billing/payment 

process. 

This interface is an external interface. 


[DF004 INS] 


Data presentation 


IN/OUT 


Data required for the encoding/decoding of messages. 


[DF004_IN4] 


HMI support 


IN/OUT 


Data required to interact with end user for the billing/payment 
process if necessary. 


[DF004_IN5] 


Security access 


IN/OUT 


Data exchanged for the security processing of billing/payment 
data. 



7.1 .5 DF005: Traffic light phase and tinning basic service (SPAT 
basic service) 

This domain facility is relevant to the ITS applications that need information about the traffic light phase and timing 
information at the intersections equipped with a traffic light. A road side ITS-S may transmit the current and planned 
traffic phase and timing information to the approaching vehicle ITS-Ss via a standardized Signal Phase and Timing 
Message (SPAT). At vehicle ITS-S that receives the SPAT message, this domain facility decodes the SPAT messages 
and provides the information to the applications, in order to support vehicle ITS-S in certain intersection safety 
applications or green light speed advisory applications as specified in [i.6]. Therefore, this domain facility may be 
implemented at road side ITS-S and at vehicle ITS-S. It shall including functionalities to construct, transmit and receive 
the SPAT message. 

In order to receive traffic light phase and timing information, the road side ITS-S shall be connected with the traffic 
light controller system. This connection may be realized by the road side equipment gateway implemented at the road 
side ITS-S as defined in clause 5.1.3. Specific national or international standards may needs to be considered to develop 
this gateway. 

At receiving ITS-S, the received SPAT information should be matched to the intersection topology in order to correctly 
understand to which road section or lane section that the traffic light phase and timing is relevant. The intersection 
topology information may either be transmitted by the road side ITS-S in a road topology message (TOPO message). 

In a potential deployment scenario, a road side ITS-S may first announce the availability of the SPAT information via a 
service announcement message (SAM) as defined in clause 6.2.5. At receiving side, the receiving ITS-S needs to 
interact with the management layer, in order to set the receiving ITS-S to the proper conditions for the SPAT reception 
(e.g. the communication protocol and access technology being used by the road side ITS-S to transmit the SPAT 
message). 

NOTE: The TOPO domain facility is defined in clause 7.1.6. 



ETSI 



41 



ETSI TS 102 894-1 VI. 1.1 (2013-08) 



The functional block diagram of this domain facility is illustrated in figure 7.5. 
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Figure 7.5: Block diagram: SPAT basic service 

The functional requirements of this domain facility are presented in table 7.9. 

Table 7.9: Functional requirements: SPAT basic service 



Functions 


Requirement 


[DF005_F1]: 


This function shall collect traffic light phase and timing data from the traffic light controller via the road 
equipment gateway, and other data needed for the construction of SPAT messages from 
corresponding facilities. 
This function applies to the road side ITS-S. 


[DF005_F2]: 


This function shall execute the SPAT transmission protocol. It constructs a SPAT message and 
transmits the constructed SPAT as scheduled by the SPAT transmission protocol. 
This function applies to the road side ITS-S. 


[DF005_F3]: 


This function shall execute the SPAT reception protocol. It receives a SPAT message and provides 
the content of the SPAT message to the ITS applications. 
This function applies to the vehicle ITS-S. 


[DF005_F4]: 


This function shall correlate the received signal phase and timing information to the intersection 

topology. 

This function applies to the vehicle ITS-S. 
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The interfaces of this domain facility are presented in table 7.10. 



Table 7.10: Interfaces: SPAT basic service 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF005_IN1] 


ITS-S ID 

management; AID 
management; 
position 

management; time 
management and/or 
other facilities 


IN 


Data required for the construction of the SPAT message. 


[DF005_IN2] 


road equipment 
gateway 


IN 


Real time signal phase and timing information provided by the 
traffic light controller system. 


[DF005 IN31 


Data presentation 


IN/OUT 


Data required for the encoding/decoding of the SPAT message. 


[DF005 IN41 


N&T 


IN/OUT 


SPAT for transmission or received SPAT. 


[DF005_IN5] 


Service Management 


IN/OUT 


IN: Indication of the availability of SPAT service. 
OUT: Data required by the service management. 


[DF005 IN6] 


Application; LDM 


OUT 


Received SPAT data. 


[DF005 IN7] 


Security access 


IN/OUT 


Data required for the SPAT security processing. 



7.1 .6 DF006: Road topology basic service (TOPO basic service) 

This domain facility is relevant to the ITS applications that rely on a service provided from road side to inform the local 
road topology. As example, when the road side ITS-S transmits the SPAT message to the approaching vehicle ITS-S. It 
may furthermore transmit the TOPO message as well, in order to ensure that the receiving ITS-S is able to correlate the 
SPAT data corresponding to the road topology. 

However, the TOPO message may be used in other ITS-S applications not only in the traffic light equipped intersection 
area. For example, a road side ITS-S may transmit a TOPO message in order to inform the road users of a dangerous 
curve. This domain facility may be implemented at road side ITS-S and at vehicle ITS-S. It shall including 
functionalities to construct, transmit and receive the TOPO message. 

In other to overcome the issue of different map format being used in different ITS-Ss, a TOPO message may be defined 
with a format that is independent to a specific map or to a specific map provider (e.g. using the geographic coordinates 
to describe the road topology). 

In a potential deployment scenario, a road side ITS-S may first announce the availability of the TOPO information via a 
service announcement message (SAM) as defined in clause 6.2.5. At receiving side, the receiving ITS-S needs to 
interact with the management entity, in order to set the receiving ITS-S to the proper conditions for the TOPO message 
reception (e.g. the communication stack and access technology being used by the road side ITS-S to transmit the 
TOPO message). 
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The functional block diagram of this domain facility is illustrated in figure 7.6. 
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Figure 7.6: Block diagram: TOPO basic service 

The functional requirements of this domain facility are presented in table 7.11. 

Table 7.11 : Functional requirements: TOPO basic service 



Functions 


Description 


[DF006_F1]: 


This function shall collect data needed for the construction of TOPO messages from the map data 
base and from the corresponding facilities. 
This function applies to the road side ITS-S. 


[DF006_F2]: 


This function shall execute the TOPO transmission protocol. It constructs a TOPO message and 
transmits the constructed TOPO as scheduled by the transmission protocol. 
This function applies to the road side ITS-S. 


[DF006_F3]: 


This function shall execute the TOPO reception protocol. It receives a TOPO message and provides 
the content to the ITS applications and facilities that requesting the data. 
This function applies to the vehicle ITS-S. 



The interfaces of this domain facility are presented in table 7.12. 



Table 7.12: Interfaces: TOPO basic service 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF006_IN1] 


ITS-S ID 

management; AID 
management; 
position 

management; time 
management and/or 
other facilities 


IN 


Data required for the construction of the TOPO message. 


[DF006 IN21 


Map database 


IN 


IN: Road topology information. 


[DF006 INS] 


Data presentation 


IN/OUT 


Data required for the encoding/decoding of the TOPO message. 


[DF006_IN4] 


N&T 


IN/OUT 


IN: Received TOPO from ITS networking and transport layer. 
OUT: TOPO for transmission by ITS networking and transport 
layer. 


[DF006_IN5] 


Management 


IN/OUT 


IN: Indication of the availability of TOPO service. 
OUT: Data required by the management. 


[DF006 IN6] 


Application; LDM 


OUT 


Received TOPO data. 


[DF006_IN7] 


Security access 


IN/OUT 


Data required for the TOPO security processing. 
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7.1 .7 DF007: In vehicle signage basic service (IVS basic service) 

This domain facility is relevant to the ITS applications that rely on a service provided from road side ITS-S or central 
ITS-S, to inform the road side signage information to the road users via the wireless communications. The road side 
signage information may include the static road signage information such as speed limit, school zone, crossing priority, 
etc. and the dynamic information such as information provided by the Variable Message Sign. 

Road side ITS-S obtains the road signage information via the road equipment gateway or from a static configuration of 
the application (for static road signage). In case that the road signage information is provided by a central ITS, for 
example a traffic management operator manages the VMS information in real time. The central ITS-S may provide 
directly the information to the road side ITS-S via DATEX II gateway. Alternatively, the IVS information may be 
provided directly from the central ITS-S to vehicle ITS-S. 

This domain facility constructs an IVS message with the obtained road signage information and transmits the IVS 
message to the approaching mobile ITS-Ss (vehicle ITS-S or personal ITS-S). The IVS basic service of the receiving 
ITS-S side receives the message and provide the content to an ITS applications. This application may check the 
relevance of the information and present the information to the user when necessary. This information may be used to 
assist the navigation service provided to the road user. 

In a potential deployment scenario, a road side ITS-S may first announce the availability of the IVS information via a 
service announcement message (SAM) as defined in clause 6.2.5. At receiving side, the receiving ITS-S needs to 
interact with the management layer, in order to set the receiving ITS-S to the proper conditions for the IVS message 
reception (e.g. the correct communication stack and access technology being used by the road side ITS-S to transmit the 
IVS message). 

The functional block diagram of this domain facility is illustrated in figure 7.7. 
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Figure 7.7: Block diagram: IVS basic service 
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The functional requirements of this domain facility are presented in table 7.13. 

Table 7.13: Functional requirements: IVS basic service 



Functions 


Description 


[DF007_F1]: 


This function shall collect data needed for the construction of IVS messages from gateways and from 

the corresponding facilities. 

This function applies to the road side ITS-S or to the central ITS-S. 


[DF007_F2]: 


This function shall execute the IVS transmission protocol. It constructs an IVS message and transmits 
the constructed IVS as scheduled by the transmission protocol. 
This function applies to the road side ITS-S or to the central ITS-S. 


[DF007_F3]: 


This function shall execute the IVS reception protocol. It receives an IVS message and provides the 

content to the ITS applications. 

This function applies to the vehicle ITS-S. 



The interfaces of this domain facility are presented in table 7.14. 



Table 7.14: Interfaces: IVS basic service 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF007_IN1] 


ITS-S ID 

management; AID 
management; 
position 

management; time 
management and/or 
other facilities 


IN 


Data required for the construction of the IVS message. 


[DF007_IN2] 


Road equipment 
gateway 


IN 


Road side signage data provided by the road equipment 
connected with the road side ITS-S. 


[DF007_IN3] 


DATEX II gateway 


IN 


Road side signage data provided by the central ITS-S connected 
with the road side ITS-S. 


[DF007 IN4] 


Data presentation 


IN/OUT 


Data required for the encoding/decoding of the IVS message. 


[DF007_IN5] 


N&T 


IN/OUT 


IN: TOPO message received from networking and transport 

layer. 

OUT: TOPO message delivered to networking and transport 

layer for transmission. 


[DF007_IN6] 


Management 


IN/OUT 


IN: Indication of the availability of IVS service. 
OUT: Data required by the management. 


[DF007 IN7] 


Application; LDM 


OUT 


Received IVS data. 


[DF007 INS] 


Security access 


IN/OUT 


Data required for the IVS security processing. 



7.1 .8 DF008: Community services user management 

This domain facility is relevant to a central ITS-S that provides ITS community services. The community services are 
services that are provided to a specific groups or categories of users belonging to specific communities, typically under 
contract or agreements. The user of a community may be end users that are connected to the service provision server 
using the ITS-S via HMI. The user of the community services is assigned with a client ID, this client ID is linked to a 
specific user profile, e.g. ITS-S ID, end user identification, etc. 

First of all, this domain facility shall include a client ID and user profile management function, allowing the 
identification of a user belonging to the community. This functionality is in charge of updating, adding or discarding 
user identifiers of the community members. For this purpose, this facility shall include a database of user repository, 
including community user client ID and user profiles information. For example, the database may include the vehicle 
static data such as vehicle type, vehicle description information corresponding to each user identifier for a service that is 
provided to vehicles owners (e.g. insurance service). A user profile allows unambiguous identification of each user or 
ITS-S of the community. 

Furthermore, this domain facility may provide a functionality to discover ITS-Ss (in particular the mobile ITS-Ss) and 
community users belong to a service community when these ITS-Ss enters a certain communication networks. It may 
require an access point to detect e.g. from periodical sent service announcement messages, or other means e.g. on 
demand from mobile ITS-S, and judge whether such ITS-S and user is belonging to the community. Depending to the 
requirement of use case, this facility may send request to vehicles to retrieve more detailed data for unambiguous 
identification. 
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Finally, this facility may include another functionality to monitor user data and/or dynamic data of ITS-Ss needed for 
service processing such as the position of the ITS-S, the request type from the user. 

The functional block diagram of this domain facility is illustrated in figure 7.8. 
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Figure 7.8: Block diagram: Community services user management 

The functional requirements of this domain facility are presented in table 7.15. 

Table 7.15: Functional requirements: Community services user management 



Functions 


Requirement 


[DF008_F1]: 


This function shall manage the community user IDs and user profiles information. 
It may interface with community services applications for the client ID management. 


[DF008_F2]: 


This function shall manage the data base of the user repository. It includes functionalities to generate, 
to update user repository of the community service users and to delete the invalid information. 


[DF008_F3]: 


This function shall interact with user ITS-S in order to discover a community user being susceptible to 

the service, when required by the community service application. 

This functionality is optional, it allows the service provider ITS-S to propose or initiate the community 

services. 


[DF008_F4]: 


This function shall monitor the user connectivity and user status e.g. provision, when required by the 

community service application. 

This functionality is optional, it allows the service provider ITS-S to propose or initiate the community 

services. 



The interfaces of this domain facility are presented in table 7.16. 

Table 7.16: Interfaces: Community services user management 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF008_IN1] 


Application 


IN/OUT 


IN: Data and requirements for the community user management. 
OUT: Discovered users that are susceptible to receive the 
proposed community services or user monitoring information. 


[DF008_IN2] 


User ITS-S 


IN/OUT 


Data exchanged between central ITS-S and end user ITS-Ss for 
user discovery and/or user monitoring. 
This interface is an external interface. 



ETSI 



47 



ETSI TS 102 894-1 VI .1.1 (2013-08) 



7.2 



Information support facilities functional requirements 



7.2.1 DF009: Local dynamic map (LDM) 

As defined in [i.l], the LDM is relevant to vehicle, personal ITS-S and road side ITS-S. The LDM is a database that 
provides a representation of the surrounding situation of the ITS-S based on the received messages such as CAM, 
DENM. Furthermore, the LDM may include the static map data, road traffic data (e.g. SPAT, TOPO, and IVS 
message), driving context information (e.g. weather condition) and/or highly dynamic data (e.g. sensor data, other 
vehicles data from received CAM and DENM). The content of the LDM may vary from one implementation to another. 
However, the LDM content may be organized and defined based on a standardized common data dictionary as defined 
in clause 6.3.4. Different ITS applications consult the LDM database for the application execution. 

The LDM shall have a functionality to manage the LDM data, for example to update the LDM database based upon the 
reception of new messages and updated dynamic information. In a possible implementation of the LDM, the LDM may 
include functionalities to further process the data included in the LDM for example to aggregate and correlate the data 
coming from multiple ITS-S s or multiple data sources. Finally, the LDM shall provide an API to the ITS applications, 
for it to obtain information for the application execution. 

The functional block diagram of this domain facility is illustrated in figure 7.9. 
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Figure 7.9: Block diagram: LDM 

The functional requirements of this domain facility are presented in table 7.17. 

Table 7.17: Functional requirements: LDM 



Functions 


Requirement 


[DF009_F1]: 


This function shall provide the management functionalities for the LDM database, including updating 
LDM data and discarding invalid LDM data. 


[DF009_F2]: 


This function shall provide LDM data processing functions in order to assist the application running 

and to improve the efficiency (e.g. reduce the amount of data) information exchanges with 

applications. 

This function is optional. Detailed processing rules and functionalities are depending on the system 

design of the ITS-S. 
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The interfaces of this domain facility are presented in table 7.18. 

Table 7.18: Interfaces: LDM 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF009_IN1] 


Messages 


IN 


Information for LDM update based on received 
messages. 


[DF009_IN2] 


ITS-S positioning 
service 


IN 


Current position and velocity of the ITS-S if the LDM 
includes such information. 


[DF009_IN3] 


IVlap 


IN 


Local or global map data if the LDM includes such 
data. 


[DF009_IN4] 


Applications 


IN/OUT 


Applications may send requests to LDM for obtaining 

LDM data based on certain rules (e.g. updates 

frequency). 

LDM provides data required by the applications via 

this interface. 


[DF009_IN5] 


Common data 
dictionary 


IN/OUT 


Data element definition. 



7.2.2 DF010: RSU management and communication 

This domain facility is relevant at the central ITS-S that manages the road side ITS-Ss (road side units RSU) in its 
network. The central ITS-S maintains a database of the road side ITS-Ss managed or deployed by the central ITS-S. 
This database includes information of the road side ITS-Ss required by the management, maintenance, control and the 
communication. Typically for one road side ITS-S, the following information is kept by the database: 

• Road side ITS-S identifier 

• Road side ITS-S network identifier 

• Road side ITS-S geographical position and its location referencing 

• Road side ITS-S supported applications/services 

• Road side ITS-S communication capacities 

• Road side ITS-S communication coverage 

• Road side ITS-S detection capacities 

• Road side ITS-S functioning status 

Based on this database, different types of data can be exchanged between central ITS-S and road side ITS-S: 

• Command and control data: a central ITS-S sends specific commands to control the behaviour or to upgrade 
the capacities of the road side ITS-S. On the other hand, road side ITS-S may send its operation status 
information to the central ITS-S. 

• Traffic management information: a central ITS-S may send information related to the traffic management or 
travelling information to the road side ITS-S and request the dissemination of the information to road users. 

• Traffic probe data and/or event information detected at road side: a road side ITS-S may process the received 
CAM and DENM from vehicle ITS-S and provides the information to the central ITS-S, supplementary to 
other road side detection information via other road side detection sensors e.g. induction loops, cameras. 

The communication may be initiated by the central ITS-S to the road side ITS-S, or by the road side ITS-S towards the 
central ITS-S. 
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The functional block diagram of this domain facility is illustrated in figure 7.10. 
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Figure 7.10: Block diagram: RSU management and communication 

The functional requirements of this domain facility are presented in table 7.19. 

Table 7.19: Functional requirements: RSU management and communication 



Functions 


Requirement 


[DF010_F1]: 


This function shall manage the RSU database. It enables the database update and information 
retrieving. 


[DF010_F2]: 


This function shall initiate the communication from the central ITS-S towards one or more than one 
road side ITS-Ss, in order to allow the central ITS-S to command and control the road side ITS-S. 


[DF010_F3]: 


This function shall receive information from the road side ITS-S, which enables the central ITS-S to 
monitor the road side ITS-S. 


[DF010_F4]: 


This function shall enable the central ITS-S or an external actor (e.g. road operator or RSU network 
operator) to registers or deregisters a RSU within the RSU database. 



The interfaces of this domain facility are presented in 
table 7.20. 



Table 7.20: Interfaces: Community services user management 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF010_IN1] 


Central ITS-S 
applications or 
external actors (road 
operator or RSU 
network operator) 


IN/OUT 


IN: RSU registration data. 

OUT: RSU data required by the central ITS-S applications or 

external actors. 


[DF010_IN2] 


Road side ITS-Ss 


IN/OUT 


Data exchanged for the monitoring, the control and/or the 
application of the RSUs. 



7.2.3 DF011 : Map service 



This domain facility provides map information to a facility or an ITS application when necessary. For this, a map 
matching functionality shall be provided, in order to match a geographical position to road topology and provides the 
map matched data to the requested application or facility. Within an ITS-S implementation, different map format and/or 
map matching functionality may be used. 
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The functional block diagram of this domain facility is illustrated in figure 7.11. 
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Figure 7.1 1 : Block diagram: Map service 

The functional requirements of this domain facility are presented in table 7.21. 

Table 7.21 : Functional requirements: Map service 



Functions 



Requirement 



[DF011_F1]: 



This function shall provide the map matching service when requested by application or other facilities. 



The interfaces of this domain facility are presented in table 7.22. 

Table 7.22: Interfaces: Map service 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF011_IN1] 


ITS application; 


IN/OUT 


IN: Request to map service for map matching. 




location referencing; 




OUT: Map matching information. 




station positioning 








management; other 








facilities 







7.3 Communication support facilities functional requirements 
7.3.1 DF012: Session support 

This domain facility manages the communication session between ITS-Ss. If required by an ITS application, this 
domain facility initiates, maintains, recovers and closes the communication session. If required by the ITS application, 
this domain facility may furthermore provide the report of the session status to the ITS application. 
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The functional block diagram of this domain facility is illustrated in figure 7.12. 
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Figure 7.12: Block diagram: Session support 

The functional requirements of this domain facility are presented in table 7.23. 

Table 7.23: Functional requirements: Session support 



Functions 



Requirement 



[DF012_F1] 



When required by the application, this function shall send a request to N&T to initiate a session. 



[DF012_F2] 



When required by the application, this function shall send a request to N&T to close a session. 



[DF012_F3] 



When required by the application, this function shall send a request to N&T to recover a session. 



[DF012_F4] 



When required by the application, this function shall send a session status report to the requesting 
application. 



The interfaces of this domain facility are presented in table 7.24. 

Table 7.24: Interfaces: Session support 



Interface 


Related component 


Direction 


Information exchanged over the interface 


fDF012 IN1] 


Application 


IN/OUT 


Application request and session status. 


[DF012 IN2] 


N&T 


IN/OUT 


Request and session status. 



7.3.2 DF01 3: Web service support 

This domain facility implements the protocol of a web services e.g. SOAP application protocol, HTTP, etc. to enable 
the connection of an ITS-S to the Internet. Existing web service tools may be used by an application. One application 
(e.g. application implemented by a service provider at the central ITS-S) may select one or other web service tool. 

Therefore, the functional requirements of this domain facility are not presented in the present document. 

7.3.3 DF014: Messaging support 

This domain facility is mainly used for non-safety applications requiring connection between user ITS-S and the 
backend system. The messaging support manages one or several message buffer queues dynamically. The message 
buffer queues can be organized with priority levels to account for different message priorities, QoS objectives, 
and - indirectly - for the intermittent connectivity of vehicles. Optionally for the ITS applications that are transmission 
delay tolerant, the messaging support provides functions to recover the message transmission and reception due to the 
intermittent connectivity of vehicle ITS-Ss to the service provision networks via a e.g. publish/subscribe message 
broker function. This function allows an asynchronous event-based communication. This supports the communication 
over unreliable point-to-point connections and allows for a decoupling between interacting entities. 
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This facility handles all events related to the client service. In this context, an event is an instance of information 
exchange between a back end system and any external entities, e.g. an ITS-S belonging to the service community, 
external service provider or external content provider. Different communication patterns may be used between a user 
ITS-S and the backend system. This domain facility makes decision whether to pull information that of its interests or to 
push information to the external entities as long as the connection is available. This component also provides buffering 
mechanisms for outgoing and incoming messages from web service. The event handler functionality is closely linked 
with applications to manage and update an event message queue when the session is broken. This function will ensure 
the service continuity between user ITS-S s and service provider. 

The functional block diagram of this domain facility is illustrated in figure 7.13. 
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Figure 7.13: Block diagram: Messaging support 

The functional requirements of this domain facility are presented in table 7.25. 

Table 7.25: Functional requirements: Messaging support 



Functions 


Description 


[DF014_F1]: 


This function shall recover the message transmission and reception in the intermittent 

connectivity between user ITS-Ss and backend systems. 

The message transmission may be established by a push (publish) mode or a pull mode 

(subscribe). 


[DF014_F2]: 


This function shall maintain the message queues based on a defined order for example the 
priority level. 


[DF014_F3]: 


This function shall handle message queues based on event, and select the push/pull functions to 
be used based on application requirements. 



The interfaces of this domain facility are presented in table 7.26. 

Table 7.26: Interfaces: Messaging support 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF014 IN1] 


N&T 


IN/OUT 


Messages to be sent and to be received. 


[DF014 IN2] 


Applications 


IN/OUT 


Application data and parameters to manage the message queue 
and the communication pattern to be used between user ITS-S 
and back end systems. 



7.3.4 DF01 5: E2E (end to end) Geocasting 

This domain facility specified in [i.6] is used for disseminating messages to vehicle ITS-Ss in geographical area in case 
a direct connection with a central ITS-S is available. This facility may be invoked both from a vehicle ITS-S in a 
vehicle to vehicle end to end scenario and from ITS-S in a infrastructure to vehicle scenario. From a functional point of 
view it provides an alternative way in respect to geonetworking protocols as specified in [i.7] for multi hop 
dissemination of messages. From an operational point of view this facility allows the integration of wide area and local 
area wireless access. 
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The configuration/activation of this faciUty depends on CF014: Addressing mode (see clause 6.4.1). 
The following facilities may invoke it, as alternative to interface directly with the N&T layer: 

CF008: Service announcement message (SAM) processing; 

DFOOl: DEN basic service; 

DF002: CA basic service; 

DF005: Traffic light signal phase and timing message basic service (SPAT basic service); 

DF006: Road topology message basic service (TOPO basic service); 

DF007: In vehicle signage message basic service (IVS basic service). 

For the purpose of message dissemination, the geographical destination area is divided into grids that correspond to a 
number of service areas for vehicular and personal ITS-S. The grid identifier may be used as addressing scheme. 

This facility is split in two roles, i.e. as server in case of central ITS-S with a direct connection to a vehicle ITS-S, or as 
client in a vehicle or personal ITS-S. 

The server side of the DF015 may be implemented as a specific instantiation of an ITS-S in physical equipment. 

The functional block diagram of this domain facility is illustrated in figure 7.14. 



Server role 



Application 



DF015 IN2 



T 



DF015: E2EGeocasting 



DF015_F1: 

Message 

dissemination 



DF015_F2: 

Grid 

management 



DF015 INI 



T 



DF015 IN3 



N&T 



T 



Data 
presentation 



Client role 



Application 



1 



Messages 



DF015 IN2 



i 



J 



DF015: E2EGeocasting 



DF015_F3: 

Message 

transmission 



DF015_F2: 

Grid 

management 



DF015 INI 



T 



N&T 



Figure 7.14: Block diagram: E2E Geocasting 

The functional requirements of this domain facility are presented in table 7.27. 

Table 7.27: Functional requirements: E2E Geocasting 



Functions 


Description 


[DF015_F1]: 


This server side function shall send the received geo-referenced message to all ITS-Ss in the 
relevant geographical area using the corresponding grid information. 


[DF015_F2]: 


This function shall manage grids (servers) or updates location (client) with its counterpart in the 
server/client architecture. 


[DF015_F3]: 


This client side function shall send message intended for geo-referenced distribution. It may be 
invoked by messages facilities such as CA and DEN basic services. 
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The interfaces of this domain facility are presented in table 7.28. 



Table 7.28: Interfaces: E2E Geocasting 



Interface 


Related component 


Direction 


Information exchanged over the interface 


[DF015_IN1] 


N&T 


IN/OUT 


Messages to be sent and to be received, including control 
messages for grid updating. 


[DF015_IN2] 


Applications and/or 
messages facilities 


IN 


Messages from application (in the ITS Application layer or in the 
ITS facility layer) requesting geo-referenced broadcasting. 


[DF014_IN3] 


Data Presentation 


IN/OUT 


Import the data presentation from the common data dictionary 
and message encoding/decoding support in case modification of 
the messages is needed. 





8 



Conformance 



The requirements specified in the present document describe the general operation of different elements in the ITS-S 
facilities layer. They are not intended to be tested on their own. Detailed specifications are to be defined for each 
specific facility for conformance test purpose. As example, specifications of facilities CA and DEN basic services can 
be found in [2] and [3]. 
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